Method for clock recovery using updated timestamps

ABSTRACT

A method and mechanism for adaptive clock recovery of a service clock of a constant bit rate (CBR) service transmitted as a stream of packets over a packet network from a sending end node to a receiving end node via at least one intermediate node. The intermediate node associates the data packets relating to the CBR service with updated timestamps generated by a second reference timing signal available in the intermediate node. When recovering the service clock in the receiving end node, an adaptive clock recovery mechanism uses the updated timestamps to derive an estimated service clock, thereby reducing the effect of network-caused packet delay variation on clock recovery.

TECHNICAL FIELD

The present invention relates to methods and arrangements for clockrecovery in telecommunications systems, and more particularly, to clockrecovery for a Constant Bit Rate (CBR) service transported over a packetnetwork.

BACKGROUND

Packet networks were originally built to transport asynchronous data.However, today it is common to create hybrid packet/circuit environmentswhich combine packet technologies, such as ATM (Asynchronous TransferMode), IP (Internet Protocol) and Ethernet, with traditional TDM (TimeDivision Multiplex) systems. TDM services have strict synchronizationrequirements. A packet network transporting a TDM signal shall providecorrect timing at its traffic interfaces. One important aspect when TDMsignals are carried over packet networks is therefore clock recovery.

Synchronization in TDM networks is well understood and implemented.Typically, a TDM circuit service provider will maintain a timingdistribution network, providing synchronization traceable to a PrimaryReference Clock (PRC, i.e., a clock compliant with ITU-T RecommendationG.811). Synchronization is required in order to meet network performanceand availability requirements.

The timing requirements that apply when TDM signals are transportedthrough packet networks relate to jitter and wander limits at trafficand/or synchronization interfaces, long term frequency accuracy andtotal delay. Large amounts of jitter and wander will arise if thenetwork synchronisation is poor which will result in service problemscausing high error rates and possibly service unavailability. Networksynchronization needs must thus be carefully considered when networksare deployed.

There are several known methods for recovering the service clock of aConstant Bit Rate (CBR) service (e.g. a Circuit Emulated TDM signal)transported over a packet network. These methods can be divided intothree main types of methods;

-   -   Network synchronous methods: when transmitter and receiver have        access to the network clock (usually a PRC traceable reference),        and the service clock is synchronous with the network clock.    -   Differential methods: when transmitter and receiver have access        to the network clock (usually a PRC traceable reference), but        the service clock is carried asynchronously over the packet        network.    -   Adaptive methods: when transmitter and receiver have no access        to the network clock and the service clock is carried        asynchronously over the packet network.

These different types of methods have different characteristics. Networksynchronous and differential methods can guarantee the best performance.However both require the distribution of an accurate reference timingsignal, traceable to a PRC to all the end equipment.

The problem on how to distribute the reference timing signal in thepacket network is thus closely related to the issue of TDM clockrecovery. The main approaches are either to use a PRC distributedarchitecture (e.g. using GPS, Global Positioning System, based clocks),or to distribute the timing from an accurate master (Primary ReferenceClock) to the end nodes. This can be achieved either using the physicallayer, when this is synchronous (e.g. SDH, or synchronous EthernetPhysical layer which is going to be standardized by ITU-T in thedocument “G.8261 Timing and Synchronization aspects in packet networks”,published in May 2006), or via new methods based on an adaptive approach(e.g. using NTP (Network Time Protocol) described in “RFC 1350 NTPNetwork Time Protocol” published by the Internet Engineering Task Force(IETF) in March 1992 or the protocol described in “IEEE-1588™ Standardfor a Precision Clock Synchronization Protocol for Networked Measurementand Control Systems”, published by IEEE in 2002).

With the Network synchronous methods, the timing transparency of the TDMservice clock is not preserved, i.e. the outgoing service clockfrequency does not replicate the incoming service clock frequency. Thedifferential methods are implemented when timing transparency of TDMservice clock is required instead.

The third class of methods, adaptive methods, are those implemented whenan accurate reference timing signal is not available in the end node,and timing transparency shall be maintained. This is a very commonscenario and it is thus important to address the related timing issues.

In the adaptive methods the service clock from a packet streamcontaining constant bit rate data can be recovered by means of somecomputing function that depend on the arrival time of the packets at thedestination node. There are several different known computing functionsto choose from. One problem with the adaptive methods is that they arevery sensitive to packet delay variation. If the delay of the packetsvaries, it may be perceived by an adaptive clock recovery mechanism as achange in phase or frequency of the original service clock. Thereforethe presence of packet delay variation may impair the quality of therecovered service clock.

SUMMARY

As mentioned above the adaptive methods for clock recovery of theservice clock of a constant bit rate service are very sensitive topacket delay variation. An object of the present invention is to providealternative methods and mechanisms for adaptive clock recovery thatallow for a reduction of the negative impact from packet delayvariation.

The above stated object is achieved by means of the methods andmechanism defined in the independent claims.

According to a first aspect the present invention provides an adaptiveclock recovery method for recovering a service clock of a constant bitrate, CBR, service transmitted as a stream of data packets over a packetnetwork from a sending end node to a receiving end node, via at leastone intermediate node. The method includes a step of associating datapackets relating to the CBR service with timestamps generated by a firstreference timing signal in the sending end node. The method furtherincludes a step of associating the data packets relating to the CBRservice, in at least one intermediate node, with updated timestampsgenerated by a second reference timing signal available in theintermediate node. Then, according to the method, the service clock isrecovered in the receiving end node by means of a computing function foradaptive clock recovery using the updated timestamps to derive anestimated service clock.

According to a second aspect the present invention provides an adaptiveclock recovery mechanism for recovering a service clock of a constantbit rate, CBR, service transmitted as a stream of data packets over apacket network from a sending end node to a receiving end node, via atleast one intermediate node. The mechanism includes a first timestampingmechanism located in the sending end node arranged to associate datapackets relating to the CBR service with timestamps generated by a firstreference timing signal. At least one second timestamping mechanism islocated in at least one intermediate node and is arranged to associatethe data packets with updated timestamps generated by a second referencetiming signal available in the intermediate node. The mechanism furtherincludes a service clock estimating mechanism located in the receivingend node arranged to derive an estimated service clock by means of acomputing function for adaptive clock recovery using the updatedtimestamps.

According to a third, fourth, fifth and sixth aspect the presentinvention provides respectively a method for adaptive clock recoverysupport in an intermediate node, a mechanism for adaptive clock recoverysupport in an intermediate node, a method for adaptive clock recovery ina receiving end node, and an adaptive clock recovery mechanism in areceiving end node.

An advantage of the present invention is that it allows for a reductionof the negative impact from packet delay variation on service clockrecovery of a service clock relating to constant bit rate service thatis transmitted over a packet network. Thereby the quality of therecovered service clock may be improved. The methods and mechanismsaccording to the present invention are especially advantageous to usewhen there is no accurate timing reference available in the receivingend node and the packet delay variation in the packet network is high.The reason for this is that the methods and mechanisms according to thepresent invention are less sensitive to packet delay variation thanmethods and mechanisms for adaptive clock recovery according to theprior art.

Another advantage of the present invention is that it can be easilyimplemented in existing telecommunications networks without requiringsignificant upgrades in existing telecommunications nodes.

A further advantage of the present invention is that it can easily beimplemented by means of simple adaptations of existing communicationsprotocols such as RTP (Real-Time Transport Protocol) and NTP (NetworkTime Protocol).

Further advantages and features of embodiments of the present inventionwill become apparent when reading the following detailed description inconjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a is a schematic diagram illustrating expected arrival times andactual arrival times of a stream of data packets.

FIG. 1 b is a schematic diagram illustrating an example of packet delayvariation of a group of data packets over time.

FIG. 2 is a schematic block diagram of illustrating the principle of anadaptive method for clock recovery of a service clock relating to aconstant bit rate service transmitted over a packet network.

FIG. 3 is a schematic block diagram illustrating a network architecturein which an embodiment of the present invention is implemented.

FIG. 4 is a schematic block diagram illustrating the networkarchitecture of FIG. 3 and the delay and packet delay variation ofdifferent segments of the network.

FIG. 5 is a schematic graph illustrating a reduction of packet delayvariation in data used for clock recovery, which can be achieved bymeans of the present invention.

FIG. 6 is a schematic block diagram of an extended RTP packet headerwhich may be used to implement an embodiment of the present invention.

FIG. 7 is a schematic block diagram of a network architecture in which acombined differential-adaptive method for clock recovery according tothe present invention is used.

FIG. 8 is a schematic block diagram of a service clock estimatingmechanism in a receiving end node which can be used to implement thecombined differential-adaptive method for clock recovery illustrated inFIG. 7.

FIG. 9 is a schematic block diagram illustrating a mechanism foradaptive clock recovery support in an intermediate node according to thepresent invention.

DETAILED DESCRIPTION

The present invention now will be described more fully hereinafter withreference to the accompanying drawings, in which preferred embodimentsof the invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theembodiments set forth herein; rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope of the invention to those skilled in the art. In thedrawings, like reference signs refer to like elements.

“Adaptive methods” is a generic term that refers to a class of methodswhich regenerate a clock from packet timing. These methods arepoint-to-point methods that will work transparently through differentsorts of network equipment like switches and routers.

Adaptive methods use some computing function of the arrival rate orarrival times of packets at a destination node to recover the serviceclock. FIG. 1 a illustrates an example of packet arrival times and FIG.1 b is an example of a graph of packet delay variation over time. FIG. 2is a schematic block diagram illustrating the principle of adaptiveclock recovery by means of an example. According to this example, asending end node S (here a sending IWF, InterWorking Function) will sendpackets P(i) at a constant rate over a packet network 2 to a receivingend node (IWF) R. The packet rate is derived from a service clock f_(s)at the sending IWF. At the sending IWF a network clock f_(ref) that istraceable to a PRC clock is also available. The network clock f_(ref)can in general be different from the service clock f_(s). The endequipment at the receiving IWF shall recover the service clock, f_(s).The expected arrival time of the packet P(i) at the receiving IWF isdenoted by t_(i) and the actual arrival time as calculated by a localclock f_(r) at the receiving IWF is denoted by t′_(i). The clockrecovery at the receiving IWF can then be based on a comparison of theactual arrival time t′_(i) of the packets P(i) with the expected arrivaltime t_(i). This information can be used to control a local Phase-LockedLoop (PLL) 4 as illustrated in FIG. 2. The PLL 4 includes an arrivaltime detector 5 that outputs the difference between the actual arrivaltime t′_(i) and the expected arrival time ti to a filter algorithm 6,which outputs a signal to a digital synthesiser 7 controlled by a localoscillator or clock f_(r). The digital synthesiser outputs an estimateof the service clock f′_(s). The expected arrival times t_(i) arederived from the estimated service clock f′_(s).

When the service clock f_(s) and the network clock f_(ref) aresynchronous, the expected arrival time could be directly derived fromtimestamps generated by the network clock f_(ref) in the originatingequipment and included in the packets P(i). If on the other hand theservice clock is not synchronous with the network clock that generatesthe timestamp, the frequency difference between the service clock andthe network clock shall be taken into account when recovering theservice clock in the receiving IWF. It can be noticed that in case thetime stamp is based on a reading of the network clock f_(ref) thefrequency difference would implicitly be carried by a packet by thecombination of the sequence number and the actual network clock time, asthe nominal packet rate is known.

Due to the characteristics of the adaptive methods, the quality of theregenerated clock is very much dependent on the delay variation of thepackets P(i) introduced by the packet network 2. The adaptive methodswill try to compute an estimated service clock f′_(s) that as closely aspossible corresponds to the service clock fs by minimizing thedifference between the actual arrival times t′_(i) and the expectedarrival times t_(i). However packet delay variation may falsely beinterpreted by the adaptive clock recovery mechanism as a change inphase or frequency of the service clock f_(s).

In order to reduce the impact from packet delay variation the adaptiveclock recovery calculations may be based only on the packets withminimum delay as illustrated in FIG. 1 b. Minimum delay packets areillustrated as black squares. FIG. 1 b also illustrates an increasingpacket delay variation of the packets over time which is an indicationthat there is an error in the estimated service clock f′_(s).

A packet network can be described as a chain of network elements, suchas Ethernet switches, IP routers, etc., each adding packet delayvariation due to processing and queuing.

As described above, one of the main disadvantages of the adaptivemethods for clock recovery is that they are sensitive to packet delayvariation. The present invention is therefore aiming at reducing thepossible impact of packet delay variation in the clock recovery of e.g.TDM traffic.

The basic idea that the present invention is based on is to partitionthe packet network in segments where it is possible to predict thecontribution to the total packet delay variation. By updating timestampinformation associated with the packets during the packets journeythrough the packet network, it is possible to reduce the impact ofpacket delay variation from critical sections in the packet network thatlargely contributes to the total packet delay variation. Such criticalsections may for instance comprise older generation equipment or may bebottleneck sections with lower available capacity which may lead toqueuing of packets.

This can be achieved by adding a timestamping mechanism for updatingpacket timestamps in one or several intermediate nodes that the packetswill pass on their way from the sending IWF to the receiving IWF. Inorder to be able to update the timestamps the intermediate node shouldhave access to an accurate reference timing signal e.g. GPS. Thereceiving IWF should also be adapted to use the updated timestamps inthe service clock recovery procedure.

Below embodiments of the present invention that use the RTP protocol(Real-Time Transport Protocol) will be described. However the presentinvention may also be used together with other protocols, such as e.g.AAL1 in ATM networks.

Embodiments using the NTP protocol (Network Time Protocol) fordistributing an accurate timing reference will also be described.However other equivalent protocols could also be used such as theprotocol described in standard document IEEE-1588 mentioned above.

The RTP protocol is well known to the person skilled in the art anddescribed in RFC 3550 published by the IETF in 2003. The RTP protocol isa transport protocol for real-time applications and provides informationregarding sequence number and timestamp in header information. Thetimestamp is used to relate a packet to a real point in time, which canbe used for estimation of the packet jitter and for synchronizingdifferent flows belonging to the same media. RTCP (RTP control protocol)packets are used to relate the sampling time with a reference clock. Thetimestamp in an RTP header is incremented by the packetization intervaltimes the sampling rate. For example, for speech packets containing 20ms of speech sampled at 8,000 Hz, the timestamp for each block of speechsamples increases by 160, even if the block is not sent due to silencesuppression.

In case the service that is the subject of adaptive timing recovery iscarried over RTP the service clock can be recovered using the timestampsincluded in the RTP packets, in fact this timestamp information shouldprovide the nominal sampling time.

Timestamps may be used for different purposes. However in thisapplication the focus is on timestamps that are used for frequencysynchronization (i.e. clock recovery) and the generic term“sync-timestamp” will be used for timestamps with this particularpurpose. In the case of the RTP protocol the sync-timestamp may or maynot coincide with the RTP timestamp included in the RTP header dependingon the implementation of the present invention.

An embodiment of the present invention will now be described withreference to a network architecture illustrated in FIG. 3. A TDM serviceis carried over a packet network 2 and after transportation over thepacket network 2, the service clock f_(s) should be recovered. An IWF Sis the sender end-equipment terminating the TDM flow and generating therelated packets. An IWF R is the receiving end-equipment that shallrecover the service clock f_(s) by deriving an estimated service clockf′_(s) using its own local clock with frequency f_(r).

At the sender side, i.e. sending IWF S, the network clock f_(ref) isavailable. The network clock f_(ref) is a reference timing signal withknown accuracy (here PRC quality). In the case the TDM service issynchronous with the network clock f_(ref) (i.e. traceable to a PRCsource as in case of a 2048 kbit/s service generated by a PSTN network),the TDM signal itself can be the reference timing signal that is used inthe sending IWF S. Otherwise the network clock f_(ref) could begenerated by another reference timing signal, e.g. from a local GPSreceiver.

In order to use the present invention, an accurate reference timingsignal f_(b) shall also be available in some intermediate node T. Thisreference timing signal f_(b) could be generated by a local source (e.g.a GPS receiver), or a recovered low-noise PRC traceable reference timingsignal.

In FIG. 3 TS(i) denotes a series of sync-timestamps as generated by thenetwork clock f_(ref) in the sending IWF S. These sync-timestamps maye.g. have the NTP format. The packet network 2 comprises differentnetwork segments A, B, C as illustrated in FIG. 3. According to thisembodiment of the present invention the sync-timestamp TS(i) is updatedin the intermediate node T in the network segment B where there isaccess to an accurate time server 10, in this case an NTP Time Server,either co-located (e.g. a GPS receiver), or connected via a packetnetwork with low packet delay variation. The new updated sync-timestampis denoted by TS_(b)(i). By updating the sync-timestamp information inthe packets P(i), it is possible to significantly reduce the impact ofthe packet delay variation on the clock recovery.

In FIG. 3 it is illustrated that the sync-timestamp field of the packetP(i) is updated in the intermediate node T. The packet P(i) willoriginally be provided with the timestamp TS(i) generated by the networkclock f_(ref) in the sending IWF S. However when the packet P(i) reachesthe intermediate node T the timestamp TS(i) will be updated and thepacket P(i) will receive a new timestamp TS_(b)(i) generated by thereference timing signal f_(b), which is PRC traceable.

According to the present invention the clock recovery mechanism shouldderive the estimated service clock f′_(s) by means of a calculationfunction that uses the updated timestamp TS_(b)(i) instead of theinitial timestamp TS(i). Thereby the impact from packet delay variationon the clock recovery will be reduced. This result is illustrated andexplained by means of an example in FIG. 4.

The total delay of a packet between the sending IWF S and the receivingIWF R is D_(tot), which is given by a minimum delay T_(min) plus somevariable packet delay variation pdv_(tot), i.e.

D _(tot) =T _(min) +pdv _(tot).

Since the packet network 2 has been divided into segments A, B, and C,the minimum delay through the packets and the total packet delayvariation can be divided into components representing the delaycontribution from each segment respectively, i.e.

T _(min) =T _(a) +T _(b) +T _(c)

pdv _(tot) =pdv _(a) +pdv _(b) +pdv _(c)

The arrival time t′_(i) of packet P(i) in the receiving IWF R ascalculated by a local clock is (in case the local clock at the receivingIWF R and the time stamping mechanism that generates the timestamp TS(i)have different starting times a constant offset should be added to TS(i)in order to get the actual time when packet P(i) is delivered from S,however as it does not impact the final result, it is not shown in thefollowing formulas and in the following examples)

t′ _(i) =TS(i)+D _(tot)+δ_(i),

where δ_(i) is an error due to f′_(s) not being equal to f_(s) and theestimated service clock is a function “F” of a time difference betweenthe arrival time and a timestamp:

f′ _(s) =F(t′ _(i) −TS(i))=f _(s)+ε,

where ε is an error.

By updating the timestamp TS(i), the arrival time and the estimatedservice clock can instead be computed using the updated timestampTS_(b)(i)

t′ _(i) =TS _(b)(i)+D _(tot)−(T _(a) +pdv _(a))+δ_(i)

f′ _(s) =F(t′ _(i) −TS _(b)(i))=f_(s)+ε_(b)

where ε_(b) is an error representing a difference between the estimatedservice clock f′_(s) and the service clock f_(s) when recovering theservice clock based on the updated timestamps TS_(b)(i).

Thereby the packet delay variation pdv_(a) introduced by network segmentA would be eliminated from the clock recovery computations. The onlyimpact from packet delay variation on the recovery of the service clockwould come from the packet delay variation generated network segments Band C, i.e. pdv_(b) and pdv_(c) respectively. Thus the packet delayvariation that affects the clock recovery mechanism is reduced when thepresent invention is used.

FIG. 5 provides a graphical view on the reduction of the packet delayvariation that affects the clock recovery mechanism by using anintermediate timestamping mechanism that updates the initial timestampsof the packets. The time difference between the arrival time and theupdated timestamp t′_(i)−TS_(b)(i) is significantly less impacted by thepacket delay variation in the packet network 2 if compared with thetotal time difference between the arrival time and the initial timestamp t′_(i)−TS(i). The resulting error ε_(b) can then be assumed to belower than the error ε that would have been created when the totalpacket delay variation affected the clock recovery computations.

There are several known computation functions F for adaptive clockrecovery that could be used in combination with the present invention.The function F could for instance be a simple implementation based onthe Phase Locked Loop principle. In that case that output frequency(i.e. the estimated service clock) is driven by a system minimizing thephase (or time) difference as done in traditional synchronous networks.However, the noisy characteristics of packet networks often require someadvanced methodology. Solutions may for instance be based on Kalmanfilter estimators. In addition a preselection of the input samples maybe required (only the best samples are used)

In FIG. 3 and FIG. 4 it is illustrated that an intermediate node T1 alsohas access to an accurate time reference f_(c) although not via a localtime server but via a remote time server connected via a packet networkless noisy that the packet network where traffic is carried. In thiscase the reference timing signal is communicated by means of NTP packetsto node T1. The impact from packet delay variation introduced by networksegment B would also be reduced in case node T1 can replace in its turnthe sync-timestamp TS_(b)(i) with a new updated sync-timestampTS_(c)(i). The “noise” related to the NTP packets carrying the timereference f_(c) is to be accounted, but is expected to be lower that thenoise (pdv_(b)) accumulated by the traffic packets.

A requirement for being able to implement the present invention is thatan accurate timing reference signal is available (or can be madeavailable) in the intermediate node (or nodes) that is (are) going toupdate the initial timestamps. Since intermediate nodes in existingnetworks often have access to such a time reference implementation ofthe present invention is often simple. A typical example is that telecomsites such as sites hosting BSC, RNC, MSC, MGW, Access GW, etc. oftenhave a GPS time server implemented in the site. However GPS receiverscould be expensive and/or not practical to implement in the receivingIWF R. Typically one intermediate node T would be connected to severalreceiving end nodes R so there would be considerably more receiving endnodes than intermediate nodes. Therefore one advantage of the presentinvention is that accuracy in timing recovery can be improved withoutproviding access to an accurate timing reference in the receiving endnode (i.e. receiving IWF R). It is often possible to improve theaccuracy in timing recovery by making use of already existing referencetiming information in intermediate nodes in the packet network in a newway.

There are several possible formats for the sync-timestamp used accordingto the present invention. In case of RTP packets, the sync-timestampcould in principle be the same timestamp as carried in the RTP header.This would allow a very simple implementation of the present invention.However there may be some problems with the precision and a“non-standard” use of the RTP-timestamp (as it should be a nominalsampling rate according to the RTP standard) as will be discussedfurther below. In addition it should be noticed that this implementationis only possible if the service clock f_(s) is synchronous with thenetwork clock f_(ref). A more general approach could instead be based ondefining a new specific RTP header extension carrying the new updatedsync-timestamps. Such an exemplary embodiment will be further explainedbelow.

Now an embodiment that makes use of the RTP timestamp such that thesync-timestamp is the RTP timestamp itself will be discussed. Asmentioned above this approach allows for a simple implementation but itis only possible when the service clock is synchronous with the networkclock. In fact by replacing the original RTP timestamp with the updatedsync-timestamp, the actual information on the sampling time of thepacket and therefore on the service clock itself would be lost. The newtimestamps are now carrying the information on the network clock only(e.g. GPS assuming that the timestamps are updated based on a GPSreference timing signal).

When the service clock in not synchronous with the network clock (e.g. a2048 kbit/s service may have up to 50 ppm frequency deviation from thenominal bit rate), the information on the frequency difference could infact be distributed by the timestamps according to a differential methodapproach. The sending IWF S can generate the timestamps relative to thereference clock f_(ref) and these shall not be changed in thetransmission towards the receiving IWF. Therefore the updatedsync-timestamps should instead e.g. be included in an RTP headerextension as will be explained in greater detail below.

The timestamp defined in the RTP header is 32 bits, which gives aprecision of about 15 microseconds. However, jitter and wander limits asspecified in relevant standards require a precision in the order of afew microseconds. Therefore if the present invention is to beimplemented using RTP, a header extension may be needed in order to geta better precision. By comparison, a timestamp of the NTP format is a 64bits unsigned fixed point number. This length allows a sub-nanosecondprecision.

FIG. 6 illustrates a possible format of an extended RTP header that hasbeen adapted to carry the sync-timestamp that is updated in one orseveral intermediate nodes according to the present invention. Asdescribed in RFC 3550 it is possible to include an extension in the RTPheader. In that case an extension bit 61 should be set to indicate thatthe fixed header fields are followed by a header extension 69. Theformat of the header extension is specified by means of a field 65,which indicates a new RTP profile for improved synchronization accordingto the present invention, and by means of field 66 which specifies thelength of the header extension (here 2×32 bits words). Thesync-timestamp according to the present invention may be carried infields 67 and 68. FIG. 6 also shows a fixed RTP header field 62, whichis a 16 bits field for carrying the sequence number of a RTP packet, afixed RTP header field 63, which is a 32 bits field for carrying the RTPtimestamp, and a fixed RTP header field 64, which is a 32 bits fieldcalled SSRC that identifies the synchronization source.

It can be noted that a sequence number, such as “Sequence number” (field62 in FIG. 6) in the RTP header, is needed in order to handle packetloss and misordered packets. Therefore it is advantageous to implement aproper interpolation procedure in the clock recovery mechanism in orderfor the clock recovery algorithm to work also when packets are lost.

The present invention is not limited to the use of timestamps includedin the actual user data packets e.g. RTP packets. It is also possible toimplement the present invention using dedicated timestamps that aredistributed e.g. by means of NTP to the receiving IWF separately fromthe stream of user data packets. A disadvantage of this approach is theneed to define dedicated timing connections all the way to the endnodes.

If the service clock f_(s) is different from the network clock f_(ref)it is possible to combine the adaptive method for clock recoveryaccording to the present invention with a differential method for clockrecovery as illustrated schematically in FIG. 7. In addition to thesync-timestamp TS_(b)(i) the receiving IWF will need differentialinformation d_(i) that carries information on the difference between theservice clock f_(s) and the network clock f_(ref). The differentialinformation d_(i) is generated in the sending IWF S and transmitted tothe receiving IWF R. The differential information d_(i) could forinstance be the RTP timestamp as generated by the system clock which issynchronous to the network clock f_(ref). In that case the RTP timestampcan not be replaced by the updated sync-timestamp TS_(b)(i) in theintermediate node T. The sync-timestamp will instead have to be includedin the packet header along with the RTP timestamp for instance asindicated in FIG. 6 or transmitted as a dedicated timestamp separatefrom the user data packet.

The operations in the receiving end node (IWF) R according to thecombined differential-adaptive method are illustrated schematically withan example in FIG. 8. A circuit 15 (a Phase Locked Loop circuit in thisexample) will output an estimated network clock f′_(ref). A differentialcomputing unit 16 will then output the estimated service clock f′_(s)based on the estimated network clock f′_(ref) and the differentialinformation d_(i) (the estimated service clock f′_(s) is given by theestimated network clock f′_(ref) modified by a function of thedifferential information d_(i)).

In order to implement the ideas of the present invention in an existingtelecommunications system some modifications are necessary. FIG. 9 is aschematic block diagram illustrating an intermediate node T according tothe present invention. One or several intermediate nodes that are goingto provide the updated sync-timestamps associated with the passingpackets will need access to an accurate reference timing signal f_(b).The accurate reference timing signal could e.g. be a timing signal froma co-located timing server or a timing reference that is distributedfrom another node via a high-priority timing connection. However, sincean accurate reference timing signal in many cases already is availablein many intermediate nodes, it may not be necessary to make anymodifications due to this requirement. It may however be necessary tomodify some software and/or hardware in the intermediate node(s) inorder to provide the intermediate node(s) with a timestamping mechanism20 for creating the new updated timestamps associated with the passinguser data packets. The intermediate node(s) must also include a receiver21 to be able to receive the packets with associated timestamps and,depending on the implementation of the present invention, either modifythe received packets if the sync-timestamp is included in the packet asdiscussed above or create the sync-timestamp as a dedicated timestampthat is forwarded separately to a following node or to the receiving endnode. Thus the intermediate node(s) T should also include a forwardingmechanism 22. The packets received by the receiver 21 could either bereceived directly from the sending end node S or via one or severalother nodes, such as another intermediate node T in case of animplementation in which timestamps are updated in several intermediatenodes T. Correspondingly, packets or timestamps could be forwarded tothe receiving end node R either directly or via one or several othernodes.

In order to implement the present invention in the receiving end node Rit may be necessary to modify some software and/or hardware in thereceiving end node R. The receiving end node should include a serviceclock estimating mechanism for recovering the service clock f_(s) usingthe sync-timestamps that are either included in the received user datapackets or received separately as dedicated timestamps. Such a serviceclock estimating mechanism may for instance be the mechanism illustratedin FIG. 8. If the present invention is implemented such that thesync-timestamps replace the original RTP timestamp it is important thatthe receiving end node is adapted so that it does not use thesync-timestamp for computations that should be based on the original RTPtimestamp (e.g. differential timing computations). If thesync-timestamps are included in an RTP header extension the receivingend node must be adapted to interpret the extended RTP packets andextract the sync-timestamps for use in the service clock estimatingmechanism. If the sync-timestamps are transmitted to the receiving endnode as dedicated timestamps the receiving end node will obviously haveto be adapted to handle such dedicated timestamps properly.

The above description of the present invention is based on theassumption that the data and the timing is preserved end-to-end. In caseof protocol translation in the network (e.g. from RTP to otherprotocols) some data adaptation is needed, i.e. the sync-timestamp wouldneed to be translated into a new data format.

From the description above the person skilled in the art will realizewhat software and/or hardware modifications are necessary and/orsuitable in different telecommunications nodes in order to implementdifferent embodiments of the present invention.

In the drawings and specification, there have been disclosed typicalpreferred embodiments of the invention and, although specific terms areemployed, they are used in a generic and descriptive sense only and notfor purposes of limitation, the scope of the invention being set forthin the following claims.

1-34. (canceled)
 35. An adaptive clock recovery method for recovering aservice clock (f_(s)) of a constant bit rate (CBR) service transmittedas a stream of data packets (P(i)) over a packet network from a sendingend node to a receiving end node via at least one intermediate node, themethod comprising the steps of: associating by the sending end node, theCBR service data packets (P(i)) with timestamps (TS(i)) generated by afirst reference timing signal (f_(ref)); associating by at least oneintermediate node, the CBR service data packets (P(i)) with updatedtimestamps (TS_(b)(i)) generated by a second reference timing signal(f_(b)) available in the intermediate node (T); and recovering theservice clock (f_(s)) by the receiving end node utilizing the updatedtimestamps (TS_(b)(i)) to derive an estimated service clock (f′_(s)).36. The method according to claim 35, wherein: the data packets (P(i))are Real-Time Transport Protocol (RTP) packets; the timestamps (TS(i))generated by the first reference timing signal (f_(ref)) are included inthe data packets as RTP timestamps in headers of the data packets; andthe updated timestamps (TS_(b)(i)) are included in the data packets(P(i)) such that the updated timestamps replace the RTP timestamps inthe data packet headers respectively.
 37. The method according to claim35, wherein the updated timestamps (TS_(b)(i)) are included in the datapacket headers together with the timestamps (TS(i)) generated by thefirst reference timing signal (f_(ref)).
 38. The method according toclaim 37, wherein the data packets (P(i)) are Real-Time TransportProtocol (RTP) packets with extended RTP headers comprising a headerextension for carrying the updated timestamps (TS_(b)(i)).
 39. Themethod according to claim 35, wherein the updated timestamps (TS_(b)(i))are transmitted to the receiving end node over a dedicated timingconnection as dedicated timestamps, which are transmitted separatelyfrom the data packets (P(i)).
 40. The method according to claim 39,wherein the updated timestamps (TS_(b)(i)) are transmitted to thereceiving end node utilizing the Network Time Protocol (NTP).
 41. Themethod according to claim 35, further comprising: generating by thesending end node, differential information indicative of a timingdifference between the service clock (f_(s)) and the first referencetiming signal (f_(ref)), transmitting the differential information tothe receiving end node; and utilizing the differential information bythe receiving end node when recovering the service clock (f_(s)) tocompensate for the timing difference between the service clock (f_(s))and the first reference timing signal (f_(ref)).
 42. The methodaccording to claim 35, wherein the step of recovering the service clock(f_(s)) by the receiving end node includes utilizing a difference(t′_(i)−TS_(b)(i)) between an arrival time (t′_(i)) of a selected datapacket of the CBR service data packets (P(i)) and the updated timestamp(TS_(b)(i)) associated with the selected data packet to recover theservice clock (f_(s)).
 43. The method according to claim 35, wherein thesecond reference timing signal (f_(b)) in at least one firstintermediate node is a timing signal from a time server co-located witha first intermediate node or a timing signal from a remote time serverthat is available in the first intermediate node via a timingconnection.
 44. An adaptive clock recovery mechanism for recovering aservice clock (f_(s)) of a constant bit rate (CBR) service transmittedas a stream of data packets (P(i)) over a packet network from a sendingend node to a receiving end node via at least one intermediate node, themechanism comprising: a first timestamping mechanism located in thesending end node arranged to associate the CBR service data packets(P(i)) with timestamps (TS(i)) generated by a first reference timingsignal (f_(ref)); at least one second timestamping mechanism located inat least one intermediate node arranged to associate the CBR servicedata packets (P(i)) with updated timestamps (TS_(b)(i)) generated by asecond reference timing signal (f_(b)) available in the intermediatenode; and a service clock estimating mechanism located in the receivingend node for deriving an estimated service clock (f′_(s)) utilizing theupdated timestamps (TS_(b)(i)).
 45. The mechanism according to claim 44,wherein: the CBR service data packets (P(i)) are Real-Time TransportProtocol (RTP) packets; the first timestamping mechanism places thetimestamps (TS(i)) generated by the first reference timing signal(f_(ref)) in the data packets as RTP timestamps in headers of the datapackets; and the second timestamping mechanism places the updatedtimestamps (TS_(b)(i)) in the data packets (P(i)) such that the updatedtimestamps replace the RTP timestamps in the data packet headers. 46.The mechanism according to claim 44, wherein the second timestampingmechanism places the updated timestamps (TS_(b)(i)) in the data packetheaders together with the timestamps (TS(i)) generated by the firstreference timing signal (f_(ref)).
 47. The mechanism according to claim46, wherein the CBR service data packets (P(i)) are Real-Time TransportProtocol (RTP) packets with extended RTP headers comprising a headerextension for carrying the updated timestamps (TS_(b)(i)).
 48. Themechanism according to claim 44, wherein the intermediate node includesa forwarding mechanism for transmitting the updated timestamps(TS_(b)(i)) to the receiving end node over a dedicated timing connectionas dedicated timestamps such that the dedicated timestamps aretransmitted separately from the data packets (P(i)).
 49. The mechanismaccording to claim 48, wherein the forwarding mechanism transmits theupdated timestamps (TS_(b)(i)) to the receiving end node utilizing theNetwork Time Protocol (NTP).
 50. The mechanism according to claim 44,further comprising: a differential information generating mechanism inthe sending end node for generating differential information indicativeof a timing difference between the service clock (f_(s)) and the firstreference timing signal (f_(ref)); and a forwarding mechanism fortransmitting the differential information to the receiving end node;wherein the service clock estimating mechanism utilizes the differentialinformation when recovering the service clock (f_(s)) to compensate forthe timing difference between the service clock (f_(s)) and the firstreference timing signal (f_(ref)).
 51. The mechanism according to claim44, wherein the service clock estimating mechanism utilizes a difference(t′_(i)−TS_(b)(i)) between an arrival time (t′i) of a selected datapacket of the CBR service data packets (P(i)) and the updated timestamp(TS_(b)(i)) associated with the selected data packet.
 52. The mechanismaccording to claim 44, wherein the second reference timing signal(f_(b)) in at least one first intermediate node is a timing signal froma time server co-located with a first intermediate node or a timingsignal from a remote time server that is available in the firstintermediate node via a timing connection.
 53. A method for adaptiveclock recovery support in an intermediate node, the method comprisingthe steps of: receiving a stream of data packets (P(i)) transmitted overa packet network from a sending end node, the stream of data packets(P(i)) relating to a constant bit rate (CBR) service having a serviceclock (f_(s)), wherein the data packets are associated with timestamps(TS(i)) generated by a first reference timing signal (f_(ref));associating the data packets (P(i)) with updated timestamps (TS_(b)(i))generated by a second reference timing signal (f_(b)) available in theintermediate node; and forwarding the data packets (P(i)) and theassociated updated timestamps (TS_(b)(i)) to a receiving end node, whichderives an estimated service clock (f′_(s)) using the updated timestamps(TS_(b)(i)).
 54. The method according to claim 53, wherein: the CBRservice data packets (P(i)) are Real-Time Transport Protocol (RTP)packets; the timestamps (TS(i)) generated by the first reference timingsignal (f_(ref)) are included in the data packets as RTP timestamps inheaders of the data packets; and the updated timestamps (TS_(b)(i)) areincluded in the data packets (P(i)) such that the updated timestampsreplace the RTP timestamps in the data packet headers.
 55. The methodaccording to claim 53, wherein the updated timestamps (TS_(b)(i)) areincluded in the data packet headers together with the timestamps (TS(i))generated by the first reference timing signal (f_(ref)).
 56. The methodaccording to claim 55, wherein the CBR service data packets (P(i)) areReal-Time Transport Protocol (RTP) packets with extended RTP headerscomprising a header extension for carrying the updated timestamps(TS_(b)(i)).
 57. The method according to claim 53, wherein the updatedtimestamps (TS_(b)(i)) are transmitted to the receiving end node over adedicated timing connection as dedicated timestamps, which aretransmitted separately from the data packets (P(i)).
 58. The methodaccording to claim 57, wherein the updated timestamps (TS_(b)(i)) aretransmitted to the receiving end node utilizing the Network TimeProtocol (NTP).
 59. The method according to claim 53, wherein the secondreference timing signal (f_(b)) is a timing signal from a time serverco-located with an intermediate node or a timing signal from a remotetime server that is available in the first intermediate node via atiming connection.
 60. A mechanism for adaptive clock recovery supportin an intermediate node, the mechanism comprising: a receiver forreceiving a stream of data packets (P(i)) transmitted over a packetnetwork from a sending end node, the stream of packets relating to aconstant bit rate (CBR) service having a service clock (f_(s)), whereinthe CBR service data packets (P(i)) are associated with timestamps(TS(i)) generated by a first reference timing signal (f_(ref)); atimestamping mechanism for associating the CBR service data packets(P(i)) with updated timestamps (TS_(b)(i)) generated by a secondreference timing signal (f_(b)) available in the intermediate node; anda forwarding mechanism for forwarding the CBR service data packets(P(i)) and the associated updated timestamps (TS_(b)(i)) to a receivingend node, which derives an estimated service clock (f′_(s)) using theupdated timestamps (TS_(b)(i)).
 61. The mechanism according to claim 60,wherein: the CBR service data packets (P(i)) are Real-Time TransportProtocol (RTP) packets; the timestamps (TS(i)) generated by the firstreference timing signal (f_(ref)) are included in the data packets asRTP timestamps in headers of the data packets; and the timestampingmechanism places the updated timestamps (TS_(b)(i)) in the data packets(P(i)) such that the updated timestamps replace the RTP timestamps inthe data packet headers.
 62. The mechanism according to claim 60,wherein the timestamping mechanism places the updated timestamps(TS_(b)(i)) in the data packet headers together with the timestamps(TS(i)) generated by the first reference timing signal (f_(ref)). 63.The mechanism according to claim 62, wherein the CBR service datapackets (P(i)) are Real-Time Transport Protocol (RTP) packets withextended RTP headers comprising a header extension for carrying theupdated timestamps (TS_(b)(i)).
 64. The mechanism according to claim 60,wherein the forwarding mechanism transmits the updated timestamps(TS_(b)(i)) to the receiving end node over a dedicated timing connectionas dedicated timestamps such that the dedicated timestamps aretransmitted separately from the data packets (P(i)).
 65. The mechanismaccording to claim 64, wherein the forwarding mechanism transmits theupdated timestamps (TS_(b)(i)) to the receiving end node utilizing theNetwork Time Protocol (NTP).
 66. The mechanism according to claim 60,wherein the second reference timing signal (f_(b)) is a timing signalfrom a time server co-located with the intermediate node or a timingsignal from a remote time server that is available in the firstintermediate node via a timing connection.
 67. A method for adaptiveclock recovery in a receiving end node, the method comprising the stepsof: receiving a stream of data packets (P(i)) transmitted over a packetnetwork from a sending end node to the receiving end node via at leastone intermediate node, the stream of packets (P(i)) relating to aconstant bit rate (CBR) service having a service clock (f_(s)), whereinthe CBR service data packets (P(i)) are associated with updatedtimestamps (TS_(b)(i)) generated by a second reference timing signal(f_(b)) in the intermediate node; and recovering the service clock(f_(s)) utilizing the updated timestamps (TS_(b)(i)) to derive anestimated service clock (f′_(s)).
 68. An adaptive clock recoverymechanism in a receiving end node, the mechanism comprising: a receiverfor receiving a stream of data packets (P(i)) transmitted over a packetnetwork from a sending end node to the receiving end node via at leastone intermediate node, the stream of packets (P(i)) relating to aconstant bit rate (CBR) service having a service clock (f_(s)), whereinthe CBR service data packets (P(i)) are associated with updatedtimestamps (TS_(b)(i)) generated by a second reference timing signal(f_(b)) in the intermediate node; and a service clock estimatingmechanism for deriving an estimated service clock (f′_(s)) utilizing theupdated timestamps (TS_(b)(i)).